同一組模型權重，放進不同的 serving runtime，可能呈現完全不同的啟動時間、記憶體占用、併發能力與故障模式。模型回答得好不好只是選型的一部分；服務能否承受尖峰、能否觀測、資源能否預測，才是營運階段每天面對的問題。

Ollama 與 vLLM 都能提供模型 API，但產品定位與預設行為不同。前者重視本機使用與簡化模型管理，後者則以高吞吐推論服務為核心。比較兩者時，不能只跑一次 prompt 就看每秒 token 數。

先確認比較的是同一件事

「模型名稱相同」不一定代表測試條件相同。量化格式、精度、context length、chat template、sampling 參數與最大輸出長度都會影響速度和記憶體用量。

一組可比較的條件至少包括：

• 相同模型架構與可對應的權重版本。
• 相同量化或精度；無法完全一致時，要明確記錄差異。
• 相同 prompt、輸入 token 數與最大輸出 token 數。
• 相同 temperature、top-p、stop sequence 與 chat template。
• 相同 GPU、driver、runtime 版本與測試時間窗。
• 相同的冷啟動、暖機與併發測試順序。

若 Ollama 使用量化後的 GGUF，而 vLLM 使用 BF16 或另一種量化格式，測到的結果是整套部署組合的差異，不能直接歸因於 runtime。

啟動與模型生命週期

第一個請求的延遲通常包含模型載入、記憶體配置與執行圖初始化。後續請求使用已載入模型，延遲會明顯不同，因此 cold start 與 warm request 應分開記錄。

Ollama 預設會在模型閒置一段時間後卸載，也能透過 keep_alive 控制保留時間。這種生命週期適合資源有限、模型使用頻率不固定的環境，但下一次請求可能再次承擔載入成本。

vLLM 常以長時間駐留的服務方式運作，預先配置 GPU 記憶體供模型權重與 KV cache 使用。常駐會占用較多資源，換來較穩定的暖機後延遲。兩種方式沒有絕對優劣，關鍵是流量型態與可接受的冷啟動時間。

併發行為比單次速度更重要

單一請求無法呈現排隊、batching 與 KV cache 壓力。測試應逐步增加併發，例如 1、2、4、8、16，並同時觀察：

• TTFT（Time to First Token）。
• TPOT（Time per Output Token）或 inter-token latency。
• P50、P95、P99 端到端延遲。
• 每秒完成的請求數與輸出 token 數。
• queue time、錯誤率與逾時率。
• GPU utilization、VRAM 與主機記憶體。

Ollama 可依可用記憶體載入多個模型，並允許同一模型平行處理請求；平行度和 context length 會一起放大記憶體需求。佇列超過設定上限時，服務可能回傳 503。

vLLM 透過連續批次處理請求，並提供 running requests、waiting requests、KV cache usage、queue time、TTFT、TPOT 與端到端延遲等指標。吞吐量提高時，單一請求的尾端延遲仍可能惡化，因此不能只看總 token throughput。

VRAM 不能只看一個瞬間

VRAM 使用量至少包含模型權重、KV cache、runtime workspace 與額外配置。context 越長、同時進行的 sequence 越多，KV cache 壓力通常越高。

真正需要找的是轉折點：併發增加到哪一級後，queue 開始累積、TTFT 快速上升，或服務因記憶體不足而拒絕請求。該轉折點比單次測得的最高 throughput 更適合拿來設定容量與 admission control。

也要觀察請求結束後資源是否回收、切換模型是否造成抖動，以及 OOM 後服務能否自動恢復。平均值漂亮，卻需要人工重啟才能復原的方案，不適合直接進入正式環境。

API 相容不等於營運相同

兩套服務都能提供 OpenAI-compatible API，但相容層只解決部分客戶端接入問題。部署前仍要逐項確認 streaming、structured output、tool calling、錯誤格式、逾時與取消請求等行為。

監控能力也有差異。vLLM 原生提供 Prometheus 相容的 /metrics，便於觀察 engine 與 request 指標。Ollama 的模型狀態、日誌與 API 統計可以支援基本排查；若要建立完整 SLO，通常還需要反向代理、應用程式或額外 exporter 補齊請求層指標。

怎麼選

適合 Ollama 的情境通常包括個人開發、工作站、本機 PoC、少量使用者與需要快速切換模型的環境。安裝與模型管理較簡單，能縮短從下載模型到提供 API 的距離。

適合 vLLM 的情境通常包括長時間運作的共享推論服務、較高併發、需要連續批次與完整 Prometheus 指標的環境。部署與調校成本較高，但更容易納入容量規劃與 SLO 管理。

若正式服務的流量不高，也不必因為功能較多就直接選擇較複雜的 runtime。反過來說，開發環境跑得順，也不能推論同一組設定足以承受多人同時使用。

結論

Ollama 與 vLLM 的差異不只是 API 指令或單次生成速度，而是模型生命週期、排隊、批次、KV cache、監控與復原方式的整體差異。

選型前應固定模型與輸入條件，分別測量冷啟動、暖機、階梯式併發與故障恢復。最合適的方案不是最高的單點數字，而是在目標流量下能維持延遲、錯誤率與資源使用邊界的方案。下一篇將進一步拆解併發上升時，瓶頸最先出現在哪一層。

參考資料

• Ollama FAQ
• Ollama API Introduction
• vLLM Production Metrics
• vLLM Documentation